-
Notifications
You must be signed in to change notification settings - Fork 729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starcos3x pin format #1882
Starcos3x pin format #1882
Conversation
I imagine that the PIN type needs to be set PIN-wise, which means that I guess pin_encoding needs to track the individual PINs rather than being a global property... What do you think? |
Yes, it sounds possible, but as far as I know, in practice a given card uses the same encoding for all PINs. I made a quick test of all StarCOS cards at my disposal:
The only exception is the deactivated Signature PUK encoding, but that info is not valid anyway. It is surely possible to call the function starcos_determine_pin_encoding for each PIN, on demand, but I think it is not necessary. |
I agree that most likely the PIN format is the same for every PIN on the card. I think, for now, the code can stay as is. |
Do you need to include this in the upcoming release? |
Thank you! It is not that urgent, I am working on a PKCS#15 emulator PR for the same StarCOS cards anyway. |
Oh, I wish you had said that earlier, because the PIN format would normally be something that's defined in the PKCS#15-layer and passed to the driver! Although, pkcs15-pin.c currently doesn't know the GP format, that would just be a matter of adding a new flag. I didn't suggest this solution, because Starcos currently doesn't have a specialized PKCS#15 emulator. But this is exactly what you want to add... (Note that a PKCS#15 emulator can very easily iterate through all the PIN objects and set the correct format for each one!) |
I also had the feeling that the PIN format would better fit into the PKCS15 part, but the starcos driver has explicitly set the PIN encoding for all PINs that's why I decided to fix that first. And if the PIN format is unspecified in PKCS15 than the driver can fall back to the determined encoding. The planned emulator would work with the special profile on the cards of this German federal organization. It has 2 applications: ESIGN (for authentication and decryption) and QES (for qualified signing), and both apps have a related CIA (Cryptographic Information Application), but the card has no PKCS15 application. |
Strange, from what I've seen so far it looked like CIA (ISO 7816-15) is backward compatible with PKCS#15... |
Yes, I think it should be compatible and the actual CIA looks like a PKCS#15 information structure, but it is different, for example:
OpenSC fails to parse CIA_ESIGN EF(ODF), because of the extra SEQUENCE wrapper:
It seems that the actual card profile is broken an it does not comply with the standards. |
Seems like your card issuer has messed up the meta info, because ISO 7816-15 is makes clear that
At least you can use the builtin functions for parsing by stripping the extra sequence header... |
Checklist
I have adjusted the actual starcos driver for the cards of a large German federal organization. They have StarCOS 3.4 and 3.5 cards in use, I changed the following:
I have tested it with StarCOS 3.4 and StarCOS 3.5 cards on Ubuntu with opensc-explorer and on Windows 7 signing and decrypting with the minidriver and signing with the PKCS#11 Module in Firefox.